erplogobit.JPG (7484 bytes)

September 1999, Cover Story
by Rob Hirschfeld

Bionic Software? Microsoft's Nervous System is made from DNA

Article Index

Main Article

I was skeptical when I started researching Microsoft’s interlocking buzzwords: Digital Nervous System (DNS) and Digital interNetwork Architecture (DNA).  I expected an example of the MICROSOFT marketing engine maneuvering to sell vapor instead of technology.  However, once past the slick marketing and fancy graphics, I discovered Microsoft has assembled something worth considering.

Digital Nervous Systems

Your body’s Nervous System is the ultimate computer.  It uses electrical connections, nerves, to turn ideas into action.  You do not think out complete instructions for controlling your body: your nervous system just does it.  Your thoughts are translated directly into actions and your heart beats with minimal supervision.

Your business’ Nervous System, its computers and networks, should strive for the same level of integration.  Your information systems should let your company’s employees to turn ideas into throughput and revenue.  If you achieve a true Digital Nervous System (DNS) then using your computers to turn ideas into products should be as natural and effortless as breathing.  Unfortunately, today’s DNS is more like an ant colony where the parts work together, but are only loosely connected. 

In practical terms, your company’s DNS is all the your computers and the wires that hook them together.  It is more than your local area network because it includes all the servers, PCs, and special purpose hardware (e.g.: PLCs or PBXs).  It even includes computers at trading partners and customers accessing your computers via the Internet or private network. 

It is a challenge to create a true DNS with today’s technology.  There are two approaches: centralization or diversification.  With centralization, you try to consolidate everything onto a single computer like a Mainframe.  In this approach, your central computer “brain” controls everything with dumb parts that can only follow simple instructions.  With diversification, you spread your computer power between PCs attached to specialized servers and then try to integrate all the information so the distributed parts work in concert.  The components of the distributed system must be smart enough to both handle their own tasks and coordinate with the other computers.

 The free market has been driven strongly towards the diversity approach.  Diversity brings many benefits:

  • Flexibility
  • Vendor independence
  • Best-in-breed software
  • Increased system reliability (due to spread risk)
  • Scalability of performance by adding computers
  • Ability for incremental upgrades
  • Reduced unit costs

A DNS requires integration

Unfortunately, diversity also leaves our DNS with significant integration issues.  Integration problems surface because we assemble our information systems as connections between many different computers accessing many different services (file, print, email, web, database, groupware, etc).  The complexity of the DNS explodes because these connections typically require different protocols and programming techniques.  The structure becomes as delicate as a spider web and harder to maintain.

MS introduced the Windows Digital interNetwork Architecture (DNA) framework to address the integration problems inherent in the PC architecture.  Windows DNA describes a standardized mechanism to create simple and reliable connections between programs on a single computer and between different computers on a network.  This mechanism is built upon fundamental Microsoft technologies like Object Linking and Embedding (OLE) and the Common Object Model (COM).

Windows DNA is COM (and more)

MS has been evolving the Common Object Model (COM) as its core interface for all Windows applications and services (see history of COM sidebar).  After nearly a decade of development, COM is a mature and robust technology that Microsoft has carefully woven throughout the Windows operating system.  Today’s users and vendors rely on COM’s presence as the standard way to share information between Windows programs.

While COM provides simple connections between programs on a single computer, it lacks distributed, cross-computer integration.  To address this limitation, Microsoft has extended COM with Distributed COM (DCOM) and Microsoft Transaction Server (MTS). 

DCOM and MTS allow COM to span networked computers.  This is a critical addition to COM.  COM has market acceptance, but needs the network aware extensions to fulfill Microsoft’s vision.  Ultimately, Microsoft expects Windows DNA to become the glue holding Windows applications together on single PCs, across LANs and WANs, and even over the Internet.

For example, our COM savvy programmer, Denise, creates a fifty-line Visual Basic program (VB) that fills out her time and expense reports by populating the right fields in the department’s standardized Excel spreadsheet.  She does this using Excel’s COM interface.  The COM interface allows her to push data directly into named cells in the file.  Even when the spreadsheet changes, her code keeps working.

Her manager likes the program and wants to eliminate the paperwork in the department.  He has her modify the program to directly submit the data to the corporate accounting software.  Since COM does not handle network communication with the server, Denise installs the DCOM interfaces for their software on her local PC.  These interfaces appear exactly the same as COM objects while Windows handles the network communication behind the scenes.  The code change in her VB program is trivial. 

The CIO sees Denise’s application and demands a worldwide rollout.  Denise knows that DCOM does not scale well enough for that many users so she adds MTS to coordinate and manage the DCOM traffic.  Throughout this evolution, the basic user interface program remains completely the same!

DNA makes N-tier practical

Gluing applications together is important because makes it possible to build software in a new way.  COM developers assemble programs from small modules that are easy to design, create, and test.  Windows DNA lets modules be located almost anywhere on a network so large software applications are no longer forced to depend on a single computer.  This approach to splitting large applications into smaller networked re-usable modules is called N-tier architecture.

N-tier architecture describes a specific approach to slicing software applications into manageable bites.  The idea is similar to baking a cake.  If you are making just one cake then you can handle all the tasks alone; however, the situation changes if you need to make a dozen.  For a dozen cakes, you would draft someone to mix and bake while you work on icing and decorations.  When you scale up to a thousand cakes, you would hire individuals or teams to mix, bake, ice, and decorate the cakes.  The basic steps (tiers) for making a cake are the same no matter how many you make, but you can create efficiencies by splitting the steps between multiple people.

N-tier architecture’s core concept is the same: every application has the same functional tiers.  These tiers are:

  1. Presentation: displays information to the user and get instructions
  2. Workflow: organizes the information and instructions in a meaningful way
  3. Business logic (the brains of the software): ensures that the information is accurate, follows the rules of your business, and fits with the rest of your data.
  4. Data access: organizes information for efficient storage and retrieval
  5. Data source: collects and store data

In every program that you use, you are using the software to manipulate all five tiers   Even though every program uses all five tiers, most programs do not use N-tier architecture (see n-tier sidebar). 

By definition, n-tier applications can be broken into modules on multiple computers.  Once you put the modules onto different computers, each computer and module can be optimized for a specific use like database, business logic, or user interface.  Then the networked computers can share components with other computers and applications to eliminate redundancy and further optimize performance.  In some n-tier scenarios, modules can be relocated to improve network performance for remote locations without compromising application integrity.

Applications that use Windows DNA to follow the N-tier approach bring us closer to making DNS a reality.  They distribute work between computers intelligently and use COM as the glue between their internal modules.  However, n-tier architecture is not enough.  A DNS requires that applications work together seamlessly so eventually the boundaries between applications disappear.  Eventually, applications will access pools of modules from many vendors that are spread across your network and even the Internet.

MS leads the DNS way

MS has been leading the charge for seamless integration with BackOffice, their suite of server products.  BackOffice includes Exchange for Messaging, SQL Server for Data, SMS for network management, SNA for mainframe interface, plus Proxy and IIS for Internet services.  Where other vendors’ server products try to be platform independent, Microsoft BackOffice is exclusively for Windows NT servers and can embrace Windows DNA.

This platform focus comes with both costs and benefits. Failure to support different platforms means that BackOffice has a smaller potential customer base.  However, the benefit is that the key concepts for Windows DNA have matured along with the BackOffice suite.  In order to make its software more robust, Microsoft simultaneously tunes its software for the operating system and optimizes the operating system for the software.  These optimizations are passed along to developers and users.

Early versions of BackOffice were not considered robust enough for enterprise class applications like ERP.  Therefore, Microsoft has been motivated to improve performance and scalability.  They have does this by systematically incorporating n-tier technologies into its products.  These efforts are apparent in the current version.  BackOffice offers more than performance enhancements, it delivers concrete scalability benefits to users.  When users outgrow their server capacity, the software architecture allows them to spread the load to multiple computers.

For example, previous versions of Microsoft’s SQL Server required developers to code business logic inside the database as complex and platform dependant SQL programs.  The current version greatly simplifies creating COM objects so developers can separate business logic processes from the database processes.  Now developers can reuse business logic object on multiple databases to eliminate redundancy and streamline maintenance.  As the demands grow, performance can be improved by simply moving the business logic off the database server.

Vendors embrace DNS

I interviewed two ERP vendors who are changing their products to use Windows DNA: Vendors Symix and Lilly Software Associates.  They both believe Microsoft’s architecture addresses their needs for flexibility, scalability, and integration.   They count on the software giant to work with them and address their issues.  So far both vendors are excited about their success with Windows DNA and their partnership with Microsoft.

Symix’s Windows DNA compliant product, SyteCenter, benefits from Microsoft’s on-going efforts to improve scalability.  If a client needs improved performance, they can reduce the load on their database server by moving the business logic objects to another server.  Single server clients see this as insurance for incremental upgrades instead of complete server replacement.  This built-in flexibility provides a market advantage for Symix.  They can focus on strengthening their core product knowing that Microsoft is addressing performance and scalability concerns.

Lilly Software Associates expects to migrate their product, Visual Manufacturing, to Windows DNA.  Their first all COM product, Visual Jobshop, achieves a new degree of database independence.  Now that they have moved the business logic from the database into a separate tier, they are able to support almost any database technology.  In addition, they can make extensive changes to the business logic without having to reproduce the change on every database they support.  This represents a dramatic savings.  Database independence gives Lilly the flexibility to sell into new markets and quickly adapt their product to match their client’s technology platform. 

Both vendors expect to capitalize on the COM aspects of Windows DNA.  They have found that their products port easily to the other user interfaces, like the Internet, with minimal changes.  This allows them to quickly create rich applications on other platforms without extensive rewrites.  Where competitors must maintain redundant products, Lilly and Symix can simply add features to their underlying business objects and interfaces reflect the change without recoding.  This economy translates into reliable products and that can be quickly updated for new markets like e-commerce and the Internet.

While both vendors have similar expectations for the technology, they have different approaches for implementation.  Visual Jobshop targets job shops while SyteCenter is focused on repetitive manufacturers.  Lilly is rewriting their core product into Windows DNA module by module so customers can migrate.  Symix’s goal is to introduce entire all new products with complete Microsoft look and feel.  

Symix and Lilly’s competitors are not ignoring Windows DNA, but they are not adopting it as aggressively.  Many vendors with proprietary technologies are using shortcuts to comply with Windows DNA without re-architecting their products.  This allows them to gain compatibility quickly, but will not be as robust or efficient a solution.

DNS means lower costs for users

DNS technologies benefit customers (see Customer Sidebar) by lowering total cost of ownership and simplifying integration efforts (see customer perspective side bar).  These economies are most likely to occur when users are so comfortable with the Windows environment that they immediately embrace Windows DNA. 

The companies most likely to accept Windows DNA products also tend to be all Microsoft software shops.  The customer’s acceptance of Microsoft at all levels of their organization guarantees that users will know how to use the software, system administrators will be comfortable deploying it, and all the applications will be able to share data.  An Microsoft friendly environment is most likely to quickly achieve the benefits of the architecture.

Accepting Windows DNA means users will take advantage of the open architecture for data migration, customer reports, and email integration.  Windows DNA makes it easy retrieve information that is normally hidden.  For example, a user looking up the status of an active order can open an order status COM object instead of having to build a query and decipher the database joins between 10 tables.  Both Symix and Lilly will document their interface to enable these types of integrations.

This simplification eliminates the need for a costly database administrator (DBA).  Lilly provides a dedicated layer of data management objects in addition to their business logic objects.  The extra objects let Windows DNA bypasses the need for DBA skills by handling data maintenance requests at a higher level than the database.  The data management and business objects work together to ensure that information requests are complete.  This frees users to retrieve information with confidence and lets even novice programmers update ERP data without risking data corruption.

Windows DNA can also eliminate the need for costly integrations.  COM provides good hooks that reduce the amount of time integrators must spend deciphering or duplicating database transactions.  In cases where integrations are limited to file transfer, Windows DNA provides for a richer, more responsive interface.  The cost savings continue even after implementation because using objects insulates integration programs and code from database changes.  As long as the vendor maintains the object interfaces, the integration code does not care if the underlying database or business logic changes.

Considering these factors, software users do benefit substantially from applications written with Windows DNA.  The best reductions in TCO occur when both vendors and customers fully adopt the Microsoft platform.  Even with only partial user or vendor compliance, Windows DNA can still provide substantial integration savings.  This economy explains why both Symix and Lilly are focusing their initial efforts on smaller, cost-sensitive customers who are Microsoft compliant.

Where is DNS going?

While Microsoft has built a workable foundation with Windows DNA, long-term DNS benefits are still materializing.  It will take time for vendors to adopt the architecture and then generate products.  Microsoft loose specifications like DNA-Manufacturing (DNA-M) and DNA-Financial (DNA-F) rely on vendors to define the interface and deploy the technology.

With the Windows DNA components available today, users will see important gains in ease of integration, collaboration, and maintenance.  The scalability potential of the architecture is still an emerging technology: DCOM and MTS are relatively new additions and not yet widely deployed.  This means that not many technology professionals have experience designing, deploying, and supporting distributed Windows DNA applications.  However, their experience with COM will ease the transition.

I expect the level of industry acceptance to mushroom after the release of Windows2000 (NT5).  Windows2000 incorporates DCOM and MTS as native components so the next generation of servers will be pre-enabled for Windows DNA.   When Windows DNA is built into the operating system, implementation becomes trivial and reliability increases.

Only Microsoft has the influence to drive such a sweeping architecture as a proprietary technology.  If they can reach critical mass then the DNS promises of distributed computing and software interoperability will materialize.  Applications will no longer reside on single servers, but live on distributed networks.  I predict that users will eventually rent data storage and business logic directly from their vendor via the Internet.

So far, Microsoft is on track.  Their integrated development tool, Visual Studio, makes it easy for developers to use COM at every development level.  Easy development translates into cost savings for vendors and increased usability for customers.   The bottom line is that while all users of Microsoft technologies benefit from Windows DNA, the technologies behind Microsoft’s vision of a Digital Nervous System are still in their infancy.

Sidebar: A Customer perspective on Microsoft's architecture 

Shinn Shinn, Material Manager at California Instruments in San Diego, CA, took some time to discuss why he choose SyteCenter, Symix's DNA based product, and what benefits he expects to gain from their Microsoft based architecture. California Instruments is a typical midrange rmanufacture with demanding technology needs, but a limited budget.

Shinn's objectives for the new system are as follows: rapid installation, low cost of ownership, and long life. Their previous ERP system, MAPICS on AS/400, provided almost 10 years of service and Shinn hopes their new architecture will do the same. To accomplish this goal, Shinn entirely retooling his computer systems to jump head first into the Microsoft architecture with Microsoft operating systems, Office, and BackOffice. Only halfway through his installation, Shinn is confident he made a good choice.

Confidence comes from experience. He has already installed the server software himself and at California Instruments users are doing much of the installation and migration themselves. SyteCenter's emphasis on Microsoft look and feel pays off because end user training is easy and users are able to migrate and clean the data. This independence is important to Shinn because it gives the users confidence in both the system and themselves.

Shinn is not planning custom interfaces using SyteCenter's COM object, but they are already taking advantage of easy interconnections of its open architecture. Lack of easy access to their old system created "satellites of information everywhere" as people added databases and spreadsheets to solve problems not addressed by their aging software. SyteCenter's 100 percent Microsoft inter-operability makes it easy to retrieve and update information from other programs.

Even partially through their implementation, users have already altered databases to access ERP information directly and used Excel to make bulk corrections. This translates directly into benefits like quick error recovery, shorter implementation, increased user involvement, and lower consulting costs.

When Shinn chose SyteCenter he was not trying to buy into a cutting edge technology. All of his other platform decisions are intentionally on the mature side of the innovation curve. However, he was willing to take the risk with a new product like SyteCenter because Microsoft platforms dominate the market. The bottom-line for at California Instruments: they expect an early adoption of DNA to increase their software's longevity.

Sidebar: N-tier Figure

In the figures below, the user is always at the presentation layer (at the top), the raw data is stored in the data source (at the bottom), and process boundaries (dark lines) show where layers are split between different other computers.


Classical one-tier architecture puts all the programming effort onto the users computer.  It is still very common today in programs like Access, Paradox, and even Excel.

Two-tier architecture is better known as Client/Server.  Data is managed by a dedicated database to improve multi-user performance.  Many two-tier designs locate business logic with the data server to centralize control and management.

Three-tier is the fundamental n-tier architecture.  The business logic can be split onto many computers to improve reliability and spread the processing load.

Distributed three-tier is emerging as thin-client computing with web browsers explodes.  This highly partitioned model requires well defined, optimized interfaces.

Sidebar: History of COM 

Windows fundamental architecture has been built of objects from its very beginning in the form of DLLs.  COM extends DLLs in some important ways.  First, the operating system is better at managing COM objects than DLL objects so programs are more likely to keep working even after multiple installations and COM are not supposed to overwrite previous versions.  Second, COM interfaces follow rules so they are easy to use in programs while using DLLs require very exact syntax.  Finally, COM is part of Microsoft’s Object Linking and Embedding (OLE) methodology so COM objects can be inserted into simple scripts and documents.

The table below traces the metamorphosis of COM.

Techno-Lingo

Technology Name

Introduced in Architecture

Circa

DLL

Dynamic Link Libraries

Windows 1.x

1990

OLE

Object Linking & Embedding

Windows 3.x

1991

VBX

Visual Basic Control

Windows 3.x

1993

OCX

OLE Component Control

Win32 (Win9# and WinNT)

1995

ActiveX

Marketing name for OCX

Win32

1996

COM

Component Object Model (still another name for OCX)

Win32

1997

DCOM

Distributed COM is basically

WinNT

1997

MTS

Microsoft Transaction Server improves management of DCOM

WinNT

1998

DNA

Distributed interNetwork Application is basically a mixture of all COM technologies (COM, DCOM, and MTS)

Win32 + LAN

1998

All these technologies are fundamentally the same.  COM and its many flavors are basically DLLs that follow specific conventions called interface standards that allow programs can figure out what they do automatically.

Historic note: early versions of Windows provided an alterative communication strategy known as Dynamic Data Exchange (DDE).  DDE played an important role in early Windows development and allowed programs like Excel and WonderWare to share information.  Today, use of DDE has nearly vanished as an interface in favor of COM.

Interested in reading more?  Click here for more articles.

Originally appeared in Midrange ERP, September 1999. Used with permission.